I wrote and then deleted a dozen comments, as I understood it better on each reading. I did not review all the set logic, but looking at it for the ergonomics of defining patterns.

LGTM, but I am not approver here. I understand the design, though.

For posterity, Joe and I discussed this in real time. He tells me it's fine and does not change SSA behavior:

Given input (indent for clarity only), which has exactly two "leaf" fields:

{
    "foo"                         /* struct */,
        "foo.bar"                 /* struct */,
            "foo.bar.bat"         /* struct */,
                "foo.bar.bat.qux" /* LEAF string */,
        "foo.zrb",                /* LEAF string */
}

Consider a strategy that has GetResetFields() => "foo.bar.bat". That would produce:

{
    "foo", "foo.bar", "foo.zrb"
    // note: "foo.bar.bat" and its children are culled
    // note: "foo.bar" remains, though it is empty
}

If we inverted it to an Include("foo.zrb"), that would produce:

{
    "foo", "foo.zrb"
    // note: only path elements leading to "foo.zrb" remain
}

In particular, note that "foo.bar" is absent. We didn't prune it from the old case, even though it is "empty". It didn't match anything in the new case.

In neither case did we match the "leaf" fields under "foo.bar.bat/*" (as expected).

/lgtm
/hold in case others wanna take a look.